The term “service account” generally refers to the credentials used by an enterprise application server, such as WebSphere Application Server from IBM Corp., to connect enterprise applications to a given enterprise resource (e.g., a database, a service, an external system, etc.). The service account allows the enterprise applications to access the resource, for example, to retrieve information, conduct various transactions (e.g., funds transfers, etc.), and the like. As with most enterprises, the resource often contains highly sensitive data, such as personnel information, financial information, medical information, and the like. Consequently, each service account typically has one or more credentials associated therewith, usually a user identification (ID) and a password, that are required in order to access the resource.
FIG. 1 illustrates an example of the above arrangement. As can be seen, a plurality of service accounts 100a, 100b, and 100c are stored in a directory 102, typically a searchable Lightweight Directory Access Protocol (LDAP) directory. To be more precise, one or more credentials associated with each service account 100a-c are stored in the searchable directory 102. These credentials, shown in FIG. 1 as 1, Credentials 2, and Credentials 3, typically include an ID, a password, and/or other similar access controls that are changed on a regular basis for security reasons. The credentials may then be used to access (i.e., read, write, etc.) various resources 104a, 104b, or 104c linked to the service accounts 100a-c. 
In operation, enterprise applications 106a, 106b, and 106c needing access to one of the resources 104a-c may request the credentials for that resource 104a-c. Such enterprise applications 106a-c may include, for example, banking applications, human resource applications, inventory control applications, and the like. In some arrangements, the request from the applications 106a-c may include an alias for the desired service account 100a-c rather than the actual name of the service account 100a-c so as to avoid updating the various applications 106a-c every time the name of a service account 100a-c changes. Upon receiving the alias, the directory 102 finds the corresponding service account 100a-c and returns the credentials therefor to the requesting application 106a-c. The requesting application 106a-c may thereafter use the credentials to access the resource 104a-c in a manner known to those having ordinary skill in the art.
In the above arrangement, applications 106a-c are only supposed to use credentials from service accounts 100a-c for which they are authorized. In practice, however, almost any application 106a-c may use credentials from almost any service account 100a-c as long as the application 106a-c has (or is able to obtain) the alias for that service account 100a-c. This is because the identity of the requesting application 106a-c is not usually provided to the service accounts 100a-c in an enterprise application server environment. As a result, it is difficult to prevent an application 106a-c from using a service account 100a-c to gain unauthorized access to a given resource 104a-c. 
Accordingly, what is needed is a more secure way to limit use of service accounts to applications that have been specifically authorized to use the service accounts. In particular, what is needed is a way to establish an identity for each application and to use that identity to restrict use of the service accounts only to applications that have been authorized.